The principles of a management network, which are also referred to as TMN principles (TMN: Telecommunications Management Network), define a number of management levels for the management of a communications system (e.g. of a mobile communications system) in which each level has two functions. In the managing system, each level except for the lowest level has a manager function for the level below it. In the managed system, each level apart from the uppermost level has an agent function for the next-higher level.
Fault management is, for example, an important part of TMN management. As a rule, the agent in this case plays the active role, by identifying fault events in good time and accurately to its own management level and by transmitting event reports (for example alarm reports) to the manager of the next-higher level. The transmission of event data from the agent to the manager is not critical, provided there is no disturbance to the communication mechanism between these systems. If the link between the two management levels, e.g. between agent and manager, is no longer ensured for a certain time, the agent must temporarily store the events which have occurred during this interval. This ensures that, once the communications capability has been restored, the manager is first provided as quickly as possible with an overview of the current network state, for example for active alarms in the form of a list. Secondly, the manager can build up a history of the events (event history) with as few gaps as possible, for example a history of both the active alarms and the cleared alarms.
To this end, data realignment is carried out between the agent and manager whenever a new connection is set up after a connection termination or after initialization of the agent or of the manager. All alarm data for active alarms for which faults in the agent have not yet been rectified—identifiable from the fact that they are not identified as cleared alarms—must be made available to the next-higher management level completely and as quickly as possible.
DE 197 52 614 specifies such a method and communications system for dealing with alarms, which describe a basic functionality for the manager for requesting all the alarms from the agent. In this case, the agent sends the active alarms as a sequence of standardized M-EVENT-REPORTS, which are embedded in an M-ACTION request, which is initiated by the manager at the start, and are embedded in an M-ACTION response, which is initiated by the agent at the end. These are generic CMISE-standardized (Common Management Information Service Element) procedures, which are defined in accordance with ITU-T X.710 (ITU-T: International Telecommunication Union—Telecommunication sector). ITU-T X.733 defines the contents of a standardized alarm transmission (alarm report), which is produced in accordance with the M-EVENT-REPORTS services. All the M-EVENT-REPORT which are defined in the course of this M-ACTION are correlated unambiguously for each request by using correlation information. This allows the manager to associate these M-EVENT-REPORTS with a specific request and, furthermore, to distinguish them from other “regular” M-EVENT-REPORTS.
In DE 198 01 785, it is assumed that the alarm data for active alarms is transmitted for alarm data realignment between an agent in one management level and at least one manager in a next-higher management level. Furthermore, the manager sends one or more request messages to transmit the alarm data to the agent, and receives correlation information for association of the respective request with the messages containing the alarm data which are subsequently sent by the agent.
Since the alarm data realignment process is controlled by the manager as a function of at least one parameter sent to the agent, the alarm data realignment for the manager can be configured with respect to the basic functionality. This means that it is no longer essential for the agent to send all the active alarms, but only those which are defined in more detail by the transmitted parameters. This provides the manager with a selection function for a subset from all the alarms. Standardized messages are used for this purpose.
This procedure allows the manager to specifically call those alarms which are particularly critical for the functionality and are thus important to that manager, while in the process significantly reducing the load on the interface to the agent resulting from the information flow, which is restricted to only specific alarms, in comparison to the conventional method in which all alarms are signaled automatically.
In a multimanager environment, the agent must be able to cope with tasks from a number of managers, even at the same time. On the other hand, a manager can carry out its function optimally only when all the relevant events (event reports) are received as quickly as possible from the lower-level agents. In normal conditions, e.g. when the communication between an agent and a manager, or agents and managers, is functioning, this is done by using an event reporting mechanism. In this case, after identifying an event, the agent generates a corresponding message. In addition to the alarm messages, these are, for example, messages or notifications relating to a state change, object creation, object deletion or attribute value changes (attribute value change notification). These messages are sent to event forwarding discriminators, so-called EFDs, which may be located in the agent.
The object of an EFD is to pass on or route to the manager only those reports which satisfy specific filter criteria. The manager has the capability to set up such EFDs in the agent, or to delete them, and to define the filter criteria. Each manager can thus control the information flow in accordance with its individual requirements at any time.
In an object-oriented environment, for example between a manager and an agent in a mobile radio network, each agent functionality is provided by a specific object as an instance in an object class. The object is produced as the result of a modeling activity (definition of an information model), and is known both to the manager and to the agent carrying it out.
As described, there are various situations in which general data realignment is necessary, alarms, states, configuration changes between a manager or managers and an agent or agents, going beyond the normal event reporting mechanism, for example after a connection has been cleared or after initialization of the agent or manager. This alignment is generally started in response to a manager request.
Particularly for use in a third-generation mobile radio system, such as UMTS (Universal Mobile Telecommunications System), an optimum alignment method, which is preferably capable of standardization, between a manager or managers and an agent or agents should satisfy as many of the following criteria as possible:    1. As far as possible, the method should use only standardized services/protocols and be of a generic nature, in order to avoid specific manager and/or agent implementations.    2. At least for the so-called mandatory parameters, the alignment information should include the same contents as the original notification, with this being particularly important for so-called dynamic information, such as alarms or states.    3. If the data realignment is controlled by the manager, the manager should be able to define the alignment start, and should be able to identify the alignment end, without any doubt.    4. The manager should be able to distinguish between an on-line (normal) notification and a notification which is received as a consequence of a previously started alignment procedure.    5. The notifications sent by the agent using the alignment procedure use the same EFDs as the normal notifications.    6. The same log settings as for the normal notifications apply to the notifications which are sent by the agent using the alignment procedure.    7. The manager may request a complete or only a partial alignment method, for example depending on certain parameter values.    8. In a multimanager environment, each manager should receive only those notifications which are sent as a consequence of an alignment procedure triggered by that manager itself, to be precise even when alignment processes are being carried out in parallel by a number of managers.    9. The manager can distinguish between notifications even when a number of its own alignment procedures are being carried out at the same time, for example for different data or network regions.
Until now, there have been two fundamental types of data realignment or alignment methods:
a) The manager sends a request (M-ACTION request in accordance with ITU-T Standard X.710) to the agent, containing the alignment parameters and a unique number. First, the agent sends a so-called start alignment notification—for the correlation of all the notifications sent using the alignment method with the manager request. Then the agent sends the alignment notification to all the EFD instances. The end of the alignment procedure is signaled to the manager by means of a CMISE-standardized M-ACTION response, or by means of a separate end alignment notification (CMISE: Common Management Information Service Element).
This method, which is already used in mobile radio systems, has disadvantages, since non-standardized notifications (start alignment/end alignment) are introduced. Furthermore, in a multimanager environment, the notifications which are sent using a specific alignment process are also disadvantageously received by all the other managers. This results in unnecessary notifications and notifications received more than once. The above criteria 1 and 8 are thus not satisfied.
b) The manager sends a request, a CMISE-standardized M-ACTION request, which contains the alignment parameters, also including the filter criteria for this alignment procedure. In this case, the agent must first determine the notifications which correspond to those criteria. The agent then forms an M-ACTION response with all these notifications, and sends this to the request originator or manager.
This method likewise has disadvantages, since it means a specific implementation, because the agent must first check all the potential notifications in accordance with the filter criteria contained in the M-ACTION request. This leads to the alignment procedure lasting for a longer time. Furthermore, the alignment notifications do not use the same filters with regard to the event report or event reporting (in the EFD) and with regard to the event logging (LOG) as the normal notifications. In consequence, the above criteria 1, 5 and 6 are not satisfied.